「就一個填手機的欄位而已啊」

有一次需求討論，需求方PM 給我看一張畫面草圖，上面有個報名表單，要使用者填暱稱、手機、一段備註。他講得很快：「就這三格，填一填送出，很簡單。」

我問他：「手機那格，如果有人打了 9 碼，少一碼，要怎樣？」他愣了一下：「呃……擋下來？」我再問：「什麼時候擋？他打到一半就標紅，還是按送出才一起跳？備註那格可以打多長？貼一篇文章進去會怎樣？」

他把草圖收起來：「你怎麼那麼多問題。」

這些問題不是多餘的。那三個輸入框，每一個要怎麼檢查、錯了怎麼提醒，都是要寫進需求的細節。使用者看不到這一層，需求方PM 也常常沒想到，但前端工程師接到需求第一件事就是問這些。問不出來，他只能自己判斷；判斷跟業務預期不同，下一輪就是一場會議。

區塊 6「The Data」就是在處理這件事。前面區塊 4 講功能、區塊 5 畫流程，畫面長怎樣、按了會跳哪都清楚了。到這裡要往下挖一層：那些畫面上的輸入框，每一格到底接受什麼、檢查什麼、錯了怎麼提醒。

先從畫面反推資料，不要直接問「要哪些欄位」

區塊 6 一開始，鼠勾以不會直接問「這功能需要哪些欄位」，那樣問通常只會得到一句「就基本資料啊」。它改成從畫面反推：

使用者打開這個功能的時候：
A. 畫面上會顯示什麼資訊？（名稱、金額、日期⋯）
B. 使用者需要自己填什麼？（選項目、輸入數量⋯）
C. 操作完之後，結果頁會顯示什麼？（成功訊息、紀錄編號⋯）

這樣問，需求方PM 講得出來。因為他腦中是有畫面的，只是沒有「資料」這個抽象詞。從「他看到什麼、他填什麼」切進去，資料清單自己就浮出來了。

清單列完，鼠勾以會把資料分三種來源：使用者自己填的、系統本來就有的（像會員資料）、從別的系統抓的。這個分類很關鍵，因為只有第一種，也就是使用者手動填的，才需要往下追那一整排輸入規格。下拉選單、日期選擇器這種選的、系統自動帶的，跳過就好，不用每格都從頭問一輪。

輸入規格連環問：把一個輸入框拆開來看

確認完哪些欄位是使用者手填之後，鼠勾以會針對這些欄位逐一過一遍輸入規格。我把它叫「連環問」，但它不是每格都硬問一整輪，同類型的欄位可以合併一起確認。主要是這幾項（清單會隨工具迭代增補，不是死的）：

1. 必填或選填：這欄一定要填嗎，還是可以留空？必填的通常標個紅星，沒填就擋下來。
2. 長度或數值範圍：文字欄問字數上限（名稱 20-50 字、備註 200-500 字）；數字欄改問上下限、要不要小數、能不能是負數；日期欄問可以選的範圍。
3. 允許字元：只能打數字？中英文都行？特殊符號呢？沒特別說的話，通常會擋掉 < > 這類符號避免系統出事。
4. 格式規則：有沒有固定格式？Email 要有 @、手機固定 10 碼、身分證一個英文加九個數字。
5. 唯一性（要不要查重）：這欄不能跟別人重複嗎？像同一支手機只能報名一次、帳號不能撞名。要查重的，還得順手想「撞到了怎麼提醒」。
6. 驗證時機：輸入錯了，什麼時候提醒？這項給的是選項。
7. 錯誤提示文案：錯的時候畫面顯示什麼字？「請輸入有效的 Email 格式」永遠比「格式錯誤」友善。
8. 輸入遮罩與自動格式化：要不要自動幫使用者排版？手機自動加 -、信用卡每 4 碼空格、日期自動補斜線。
9. 提示文字 Placeholder：欄位裡放一段淺色提示嗎？「請輸入 10 碼手機號碼」。
10. 字元計數器：有字數上限時，要不要在旁邊顯示「已輸入 18 / 上限 50」？備註、留言這種長欄位通常會加。
11. 貼上行為：使用者複製一大段貼進來、超過字數，怎麼辦？

光是「驗證時機」這項，鼠勾以就會把它攤成選項丟出來，因為這題需求方PM 十之八九沒想過：

輸入錯了的話，什麼時候提醒使用者？
A. 即時提醒：填完那格就馬上檢查，錯了標紅
B. 送出時提醒：按了送出，一次列出所有問題
C. 兩種都要（即時 + 送出前再檢查一次）
D. 不確定（先記下來）

「貼上行為」用同樣的方式處理，給 A 自動截斷、B 允許貼但提醒、C 直接擋三個選項。這兩項做成選項題，是因為它們沒有標準答案，屬於產品決策。開放題會讓需求方PM 卡住，選項題他幾秒就選得出來。這也是這套工具從頭到尾的原則：能給選項就不要給空白。

為什麼非得問這麼細？

一個報名表單問到這種程度，看起來確實過細，我自己也懷疑過。差別在於這些規格由誰來決定。

需求方PM 不答，這些規格不會消失，只是換人填。前端工程師會自行決定字數上限、驗證時機、錯誤文案。他填的值不一定不合理，但那是工程端的判斷，不是業務的決定。等到上線後業務發現「備註只能打 50 字、客戶想多寫一點」，就是再開一張單、再改一輪。

把這些在需求階段問完，好處很實在：

優點：

• 責任歸位：規格是業務拍板的，不是工程師猜的，上線後沒得吵。
• 前端不用回頭問：拿到需求就能直接做檢查邏輯，省掉一輪來回。
• 錯誤提示可用：文案先想好，使用者看到的會是明確的指示，而不是一句「格式錯誤」。

當然它也有代價。缺點：

• 問起來確實慢：一個表單三四個欄位，逐格過一輪，是會花掉一段時間。
• 需求方PM 的耐心有限：問到第三個欄位，配合度通常就開始下降。

所以鼠勾以留了退路：使用者表示趕時間、或覺得細節太多時，它會回「這些我先用常見做法幫你記下來，之後你再跟 IT 確認就好」，把未決的項目放進待確認清單並標記清楚，不會卡在這裡逼使用者答完。問得動就問清楚，問不動就先記下來，避免單一欄位拖住整場討論。

不只填的，還有來源跟敏感資料

輸入規格連環問是面向 A（使用者填的資料）裡最重的一段，但區塊 6 還有兩個面向。面向 B 問資料來源：每筆資料是使用者填的、系統有的、還是別的系統抓的；抓來的還要追是不是即時、會不會有延遲。面向 C 問敏感資料跟保留期限：清單裡有沒有身分證、生日、健康資料這種個資，要不要遮蔽（只顯示後四碼）、要不要加密、要保留多久。

面向 C 這段，鼠勾以會主動掃一遍前面列的清單，把可能涉及個資的欄位挑出來提醒，而不是等使用者自己想到。個資是需求方PM 最常漏掉的一類，漏掉之後法遵那關過不了，整個案子會卡更久，所以這裡設計成由工具主動標記。

小結

區塊 6 The Data 做的事，是把「使用者填什麼」這件看起來很簡單的事問到底。先從畫面反推出資料清單，分清來源，再對每一個手填欄位過一遍輸入規格：必填、字數或範圍、字元、格式、查重、驗證時機、錯誤文案、遮罩、提示、計數器、貼上行為。這一輪決定的是規格由誰拍板：業務在需求階段答，或是工程師在開發階段自行決定。最後再補上資料來源跟個資保留，資料層的內容就完整了。

Day 20 進到區塊 7「Edge Cases」：例外情境。系統不會只在一切順利時運作，斷網、重複點擊、權限不足、額度用完，這些「萬一」才是上線後真正讓人半夜被 call 起來的地方。鼠勾以怎麼用十類功能類型，動態把該想的例外一個個撈出來。

這是 iThome 鐵人賽系列文章。明天見。